---
title: Mojo roadmap
sidebar_label: Roadmap
description: A summary of our plans and priorities to improve the Mojo language
---

import { Alert } from '@mantine/core';

This page provides a high-level roadmap of how we expect the Mojo programming
language to evolve over a series of phases. This roadmap provides **directional
guidance** (not an engineering plan) and is **subject to change**. As we build,
learn, and expand Mojo's use cases, we will iterate, adapt, and invest wherever
necessary to unblock priorities.

We also periodically share roadmap updates in the [Modular forum
announcements section](https://forum.modular.com/c/modular/announcements/9).

:::note Phases

The phases below are conceptual groups of work—not version numbers—and they
have no timeline for completion. We haven't yet established a long-term
versioning scheme, finalized our approach to language evolution, or decided
what "stability" will mean or when it will happen.

:::

:::caution Work items

An empty box ⬜ indicates work that's **not started**, a barricade 🚧 is for
work **in progress**, and a checked box ✅ means it's **done**. However, this is
not an exhaustive list of work and the status might be out of date. Also, the
items in each list aren't necessarily ordered by priority and some items may be
"nice to have" and not required to complete the phase.

:::

## Mojo's north star

As described in the [Mojo vision](/mojo/vision), we created Mojo to unite
developers with a single language that provides ergonomic programming features
for accelerator hardware and that scales to solve other challenges in AI and
systems programming.

Our goals are ambitious and we're taking on challenges that many languages and
systems have struggled with for decades. We believe Mojo has the right blend of
**technology, design principles, and community-first philosophy** to succeed,
but it'll work only if we stay focused and make deliberate tradeoffs aligned
with our long-term vision.

The stakes are high—programming languages that succeed shape entire ecosystems,
support millions of developers, and define how software is built. That means we
must **resist the urge to chase short-term wins** at the expense of long-term
clarity, consistency, and quality.

Our approach is to keep short-term development focused and anchored on
measurable outcomes, while building for generality so Mojo can eventually
become a general-purpose language spanning CPUs, GPUs, and other hardware, plus
the myriad of applications that Python is used for.

We know the path won't be perfect and we'll make mistakes. But with a
strong foundation and an engaged, thoughtful community, we can **learn,
iterate, and improve together**.

## Phase 0: Initial bring-up

<Alert icon="✅" title="COMPLETE" color="success"
       style={{ marginTop: '-20px' }} />

Phase 0 focused on foundational language work: implementing the core parser,
defining memory types, functions, structs, initializers, argument conventions,
and more.

As development accelerated, multiple libraries emerged to fill immediate needs,
often overlapping in functionality (e.g., multiple pointer types). As the
language stabilized, we consolidated these libraries into a coherent and
consistent foundation.

## Phase 1: High performance CPU + GPU coding

<Alert icon="🚧" title="IN PROGRESS" color="warning"
       style={{ marginTop: '-20px' }} />

Phase 1 takes Mojo from a "prototype kernel DSL" to a viable foundation for
real-world accelerated compute workloads. This phase focuses on making Mojo a
powerful and expressive language for writing high-performance kernels on CPUs,
GPUs, and ASICs. We also want to unlock other performance use-cases for CPUs,
particularly the ability to extend Python packages in a seamless way.

But performance alone isn't enough. We're equally focused on:

- **Expressiveness** for building robust libraries
- **Good error messages** for developer productivity
- **Fast compile times** to support iteration speed

The conclusion of phase 1 is the natural point to **open source the Mojo
compiler**.

### Generics and metaprogramming features

The backbone of phase 1 is Mojo's **metaprogramming system**, combined with
a **modern generic type system** that catches errors at compile time, before
code is instantiated. The following features capture how we think Mojo should
evolve, but may change as we grow into them:

- ✅ **Compile-time constructs**: The parameter system, compile-time
interpreter, `if` and `for` loops, etc.

- ✅ **Trait unions:** Allow `Copyable & Defaultable` intersections for precise
trait conformance. See the [trait composition
proposal](https://github.com/modular/modular/blob/main/mojo/proposals/trait_composition.md).

- ✅ **Predictable dependent types:** Support advanced parametric algorithms
while avoiding rebinding.

- ✅ **Parametric comptime values:** Compute parametric values, going beyond
  types and functions. See the [parametric aliases
  proposal](https://github.com/modular/modular/blob/main/mojo/proposals/parametric_alias.md).

- ✅ **Default trait methods**: Enable static composition (mixin-style).

- ✅ **Parametric raises**: The ability to throw types other than `Error` and
therefore support higher order functions like `map` that propagate the
"raisability" of their closure argument.

- 🚧 **Closure refinement**: Improve capture modeling and unify
compile-time/runtime representations.

- 🚧 **`where` clauses**: Enable early constraint checking and better error
messages for generics. See the [where clauses
proposal](https://github.com/modular/modular/blob/main/mojo/proposals/where_clauses.md).

- 🚧 **Conditional conformance**: Allow trait conformance based on predicates
over parameters.

- 🚧 **Struct extensions**: Post-hoc type extension and better modular
refactoring. See the [struct extension
proposal](https://github.com/modular/modular/blob/main/mojo/proposals/struct-extensions.md).

- 🚧 **Linear types**: Support ownership patterns; blocked on conditional
conformance.

- ⬜ **Stabilization markers**: Mechanism to tag standard library APIs with
maturity levels.

### Python interoperability

We want Mojo to be an approachable way to extend and speed up existing Python
code. We'd like to incorporate the key features of popular libraries like
"nanobind" as a guideline:

- ✅ **Build integration**: Seamless connection between Mojo's build system and
Python packaging.

- 🚧 **Python export**: Support for exposing functions and initializers to
Python.

- ⬜ **Debugger/LSP support** for mixed Python/Mojo applications.

### Core language usability and ergonomics

Mojo should "just work" for core Python-like tasks, while offering the control
systems programmers expect:

- ✅ **Basic constructs**: Functions, structs, control flow (`if`, `for`, etc.).

- ✅ **Literal support**: Infinite-precision `int`/`float`, collections,
comprehensions.

- 🚧 **Collections**: Round out core types like `List`, `Dict`, `Iterator`,
`SIMD`, `String`, etc., to utilize the language feature set of phase 1. For
instance, see [making SIMD
comparable](https://github.com/modular/modular/blob/main/mojo/proposals/simd-comparable.md)
and the [string type
proposal](https://github.com/modular/modular/blob/main/mojo/proposals/string-design.md).

- 🚧 **Unsafe programming**: Refine `UnsafePointer` and low-level primitives.

- 🚧 **Variadic args**: Full support for `*args`, `**kwargs`.

- ⬜ **Lambda syntax** for inline closure declarations.

- ⬜ **Stable and robust toolchain**: Cross-compilation, packaging and build
system, testing and benchmarking framework in the standard library, debugger,
profiler etc. We expect to make a big dent on this, but won't fully complete
everything interesting in this space in phase 1.

### Syntax and surface language polish

These may seem small, but they significantly impact developer ergonomics and
reduce future source incompatibilities:

- ✅ **Argument conventions**: Refine `init`/`del` behaviors, naming, and
default conventions.

- ✅ **Literal refinements**: Improve reliability of infinite precision literals
using dependent types. See the [collection literal
design](https://github.com/modular/modular/blob/main/mojo/proposals/collection-literal-design.md)
and [fixing simple literals
proposal](https://github.com/modular/modular/blob/main/mojo/proposals/fixing-simple-literals.md).

- 🚧 **Attribute macros**: Replacing ad-hoc constructs like
`@register_passable("trivial")`, `@nonmaterializable`, `@value`, etc., using
traits and other existing language features (shrinking the language). For
instance, see the [upgrading "trivial"
proposal](https://github.com/modular/modular/blob/main/mojo/proposals/upgrading-trivial.md)
and [upgrading `@value`
decorator](https://github.com/modular/modular/blob/main/mojo/proposals/upgrading-value-decorator.md).

### Non-goals

We are intentionally *not* pursuing the following in phase 1:

- **Syntax sugar**: We defer most sugar until the core language is stable and
composable.

- **Untyped Python-style code**: For now, explicit `PythonObject` type
annotations are required.

- **Python library parity**: We expect there will be many missing APIs (e.g.
potentially file system APIs) in phase 1.

## Phase 2: Systems application programming

<Alert icon="⏰" title="NOT STARTED" color="danger"
       style={{ marginTop: '-20px' }} />

Once the core generic type system and systems programming features converge and
stabilize, we'll begin expanding Mojo to support application-level
programming—the kinds of problems typically addressed with languages like Rust
and C++.

That said, **we are not aiming to match Rust or C++ feature-for-feature**. Our
goal is to keep Mojo a relatively small and teachable language—one that solves
specific problems [without unnecessary
complexity](/mojo/vision#managing-language-complexity).

:::note

None of the features below are currently scoped, and we aren't interested in
design discussions about them. We list them here so we can understand non-goals
for phase 1 and rationalize how things add up over time. Our focus remains
firmly on completing phase 1 before investing significant effort here.

:::

### Language and abstraction features

- **First-class `async` support:** Fully integrated with Mojo's type and memory models.

- **Existentials / dynamic traits:** For building flexible runtime abstractions.

- **Richer metatypes:** Extending support for type-level programming.

- **Algebraic data types & pattern matching:** Enabling expressive state modeling.

- **Dynamic reflection features.**

- **Initial distributed programming support.**

### Memory safety model: fast, expressive, gradual

Mojo code should be memory-safe by default, while still being fast, expressive,
and gradually more complex for beginners. Although phase 1 provides a strong
framework for [memory safety](/mojo/manual/values/), there still exist
situations where safety is not guaranteed by default and we expect won't be
fully resolved until phase 2.

- **Fast:** Mojo should enable the programmer to write high-performance
memory-safe code by default, while continuing to provide unsafe primitives for
expert use.

- **Expressive:** Mojo's origin system should enable more mutable aliasing to
provide a more expressive programming model than languages like Rust. This is
desirable because aliased mutable objects occur widely in both the Python and
C++ communities, often for legitimate reasons of expressiveness, simplicity,
and/or performance.

- **Gradual:** We want progressive disclosure of complexity—it should be easy to
get started and be immediately productive in Mojo, and users can gradually
learn the more advanced features as they need them.

This will likely require:

- Finalize indirect origins.

- Support mutable aliasing of struct fields.

- Support mutable aliasing of function arguments.

- Prevent dereferencing any references to fields of deallocated
reference-counted objects.

- Access control features, e.g. `private` modifiers (or formalizing the
underscore convention) to prevent violating abstraction boundaries.

- Eliminate undefined behavior, especially in core types and built-in
operations.

This will get us closer to the goal of making Mojo's memory safety model fast,
expressive, and gradually more complex for beginners—making Mojo more
approachable to Python and C++ developers.

### Other application-level programming features

We might explore hygienic, importable macros to extend Mojo's surface syntax in
controlled ways. For example, enable constructs like `parallel_for` that feel
as seamless as a built-in `for` loop but that are defined in libraries.

We also might explore making the Mojo optimizer extensible with "library
defined" optimizations. For example, allow Mojo library authors to define
rewrites like `String.__add__(x, String.__add__(y, z))` into `String.concat(x,
y, z)` . The exact shape and ultimate capability of this will be defined later.

## Phase 3: Dynamic object oriented programming

<Alert icon="⏰" title="NOT STARTED" color="danger"
       style={{ marginTop: '-20px' }} />

Eventually, we want Mojo to support the core dynamic features that make Python
great, including support for untyped variables, classes, inheritance, etc. We
have some thoughts about how these features will compose into the other
features, but defer detailed planning and scoping until the earlier phases are
done.

As Mojo matures through phase 3, we believe Mojo will become increasingly
compatible with Python code and deeply familiar to Python users, except more
efficient, powerful, coherent, and safe. Mojo may or may not evolve into a full
superset of Python, and it's okay if it doesn't.

We're encouraged by how well AI-assisted coding tools already help migrate
Python to Mojo today, and we're confident that future tooling and ecosystem
maturity will make this evolution even smoother.

## Continuous investments

The following topics will remain in progress throughout Mojo's lifetime and
are not tied to any specific phase:

- **Error messages and diagnostics**: Always room for improvement, but
parameter inference and elaborator errors need improvement in particular.

- **Compile times**: We will continue pushing for faster developer iteration
cycles.

- **Standard library cleanup**: API consolidation, regularization, and new
capabilities.

- **Hardware support**: Extending Mojo's backend to support new architectures.

## Contributing to Mojo

We're committed to open-sourcing all of Mojo, but the language is still very
young and we believe a tight-knit group of engineers with a common vision moves
faster than a community-driven effort. So we will continue to plan and
prioritize the Mojo roadmap within Modular until more of its internal
architecture is fleshed out.

However, the Mojo standard library is already open sourced and we'd love to
accept your contributions there. Although this roadmap mentions some standard
library types because they depend on changes in the Mojo compiler, a lot of
work on the standard library is not accounted for here.

You can learn more about contributing to the standard library from the
contributor doc below:

- [Contributor
guide](https://github.com/modular/modular/blob/main/mojo/CONTRIBUTING.md)

If you encounter any bugs with Mojo, please
[submit an issue on GitHub](https://github.com/modular/modular/issues).
